IBIS Macromodel Task Group

Meeting date: 13 June 2023

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora Systems:               Dian Yang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                            * Liwei Zhao
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Note:  The meeting scheduled for June 6th was not held.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 30th
meeting.  Walter moved to approve the minutes.  Michael seconded the motion.
There were no objections.

--------------
New Discussion:

PSIJ Discussion:
Walter noted that Bob had previously mentioned a recent IBIS Summit presentation
on the topic.  Bob said the presentation, from the Indian Institute of
Technology Jodhpur, contained an alternate formulation that might be related
to BIRD220.  Bob said that he had reached out to the authors to see if they had
any interest in commenting on BIRD220 or the PSIJ Sensitivity proposal from
Kinger.  Bob took an AR to send information about the presentation to the ATM
list.

AMI Support for [Test Data]/[Test Load]:
Michael shared and reviewed draft1, which he had recently sent to the ATM list.
He said [AMI Test Data] is designed to be analogous to the existing [Test Load]
and [Test Data] keywords.  The principles are the same, but the goal in this new
proposal is to specify the load on the Tx (including the Rx), the stimulus, and
the output waveform data the AMI simulation is expected to generate.

Michael said the traditional [Test Load] is insufficient for AMI because its
channel description capability is limited and inputs to an AMI simulation can
not be described completely.  He said that the new proposal's most dramatic
difference from the existing keywords is that the waveform data is assumed to
live in a separate file, as it is likely too long to be included inside the .ibs
file itself.  In addition, the input pattern and AMI parameter settings are
specified.  The channel specification in the new proposal provides a reference
to an IBIS-ISS subcircuit.

Walter presented a high-level summary of what he thought Michael was proposing
that the EDA tool would do with this information:
- Simulate the Tx IBIS model (analog portion of the AMI model) with an IBIS-ISS
  subcircuit, which may or may not have an AMI Rx model as a load at the end of
  the channel, to determine the step (impulse) response.
- Once it has determined the impulse response, then it can call the Tx AMI_Init
  and Rx AMI_Init (if an Rx model exists).
- If testing AMI_GetWave, the simulator calls the Tx AMI_GetWave with the
  specified bit pattern stimulus.  The Tx AMI_GetWave returns a waveform, which
  the simulator then convolves with the impulse response.  The resulting
  waveform is what gets compared to the test waveform data for a Tx.
- The tool then passes the waveform to the Rx AMI_GetWave (if it exists) and the
  waveform returned by AMI_GetWave is what gets compared to the final test
  waveform.
So, the test waveforms are the expected outputs of AMI_Init or AMI_Getwave for
the Tx and or Rx.  This proposal is testing the ability of the EDA tool to
compute the step response, and it is also testing its ability to pass data in
and out of the executable model.

Michael said he largely agreed with this summary.  However, he noted two
important points.  He said his proposal required an AMI Rx to be included, and
he envisioned an end-to-end AMI simulation with no option for having anything
other than an AMI Rx model at the end of the channel.  He said if we need to
open up the proposal for other combinations we will have to discuss it.  He also
noted that his proposal deliberately avoided any discussion of how to compare
the waveforms.

Ambrish said he thought it was problematic to include the EDA tool's computation
of the impulse response in this process.  He said the impulse response of the
channel should be one of the specified inputs included in the test data.  If
that were done, then there would be no need to define the channel at all.  The
model maker would simply provide the initial impulse response that the EDA tool
should pass through its AMI processing.  As written, it leaves open all sorts
of troublesome issues comparing impulse responses from different tools.

Michael agreed that if we just want to test the algorithmic (executable model)
processing, then we should specify the impulse response as an input.  However,
he said this would be ignoring one of the largest issues faced by model makers.
The computation of the impulse response is where many users/tools run into
trouble before they even get to AMI processing.  Without testing the tool's
impulse response, the model maker still wouldn't have a single solution that
ensures their model is getting the right inputs and generating the right
outputs.  He said he was looking for a "one-button" solution for model makers
to test the end-to-end flow.

Fangyi agreed with Ambrish.  He said there are three things we are discussing
testing: analog AMI processing, executable model processing, and the tool's
simulation of the impulse response.  He said the first two can be tested
separately with well defined initial conditions, such as Ambrish's suggestion
that the impulse response be specified as an input.  He said he didn't think
we should be trying to test the third one at all, as this is the domain of the
simulator.  We shouldn't try to mandate what the tool does in calculating the
impulse response.  Ambrish said that if we remove the simulator specific part,
i.e., the impulse response generation, from this proposal and simply provide an
input IR, then perhaps the existing Test Load and Test Data keywords could be
upgraded to work for AMI.

Michael said he is coming from a model maker's perspective, and he is attempting
to provide a simple one-step end-to-end test for the model maker.  Fangyi said
this issue is similar to that of a foundry producing a SPICE model.  The foundry
provides a SPICE model to the circuit designer, but the circuit designer then
uses the SPICE model within their simulator of choice.

Ambrish said that trying to define testing and comparison criteria for the
tools' initial channel characterization would be a giant headache.  He said it
would be simpler to provide the impulse response as an input and perform black
box testing of the AMI model.  Once we achieve that first step, we could think
about how to deal with channel characterization later.  Michael said this
would be kicking the biggest part of the problem down the road, and we will have
to deal with it eventually.

Fangyi asked how this proposal would work if the Tx and Rx models were not from
the same model maker.  Michael agreed that this was a good point.  He said he
was thinking about it purely from a model maker's perspective, and his proposal
required a Tx and an Rx.  However, for a user looking to use Tx and Rx models
from different vendors this would be a problem.  Michael said the proposal
already has issue with having to provide models for structures that aren't part
of the actual [Component], so there are tricky issues to resolve.  Fangyi said
that if we adopt Ambrish's proposal and provide the impulse response as an
input, then we can test Tx and Rx devices independently.

Arpad asked whether we want to leave open the option for BCI testing in the
future.  Randy and Fangyi said that we would also want a way to test the clock
output (clock_times) of the Rx model.  Michael agreed with these suggestions,
and he noted that there are other complicating factors such as AMI parameter
dependencies that he had not addressed in the first draft.

Michael said he understood what Ambrish and Fangyi were proposing.  We would
include no channel model and instead provide an impulse response that the tool
can pass to the AMI models.  This would allow the Tx and Rx to be independently
tested.  It would give the tool the impulse response, the control settings, and
the waveform the user should see at the output.  He questioned whether the
impulse response is accessible by the user in most tools.  He said from a user's
perspective, the impulse response portion of the processing may not be
transparent.  Ambrish and Curtis said that the impulse responses were easily
accessible in their tools.  Wei-hsing said that a model maker developing a model
can choose to have a debug mode that captures the input impulse response the
model receives from the tool.  Wei-hsing said that during model development the
model maker may not even have access to a full-blown simulator to generate the
impulse response.  So, they might use some small utility to feed an example
impulse response to their model for testing.  Fangyi agreed that this was a good
point.  He said a model maker is probably not running any simulator when they
are writing their model.  They likely develop and test the model with an example
impulse response.

Walter suggested that what the proposal aims to support can already be done with
an EMD model today.  One could create an EMD model containing Tx and Rx models
with an IBIS-ISS subcircuit connecting them.  The AMI models could be specified
with default values for all of their parameters.  The EDA tool could import that
EMD model, run the simulations, and present the results (impulse responses,
waveforms at various places, etc.).  Michael agreed, but he said automation and
ease of use are important.  Walter said that this approach could be tried right
now, and if it is useful, we could capture additional setup and automation
details in a BIRD.

Arpad suggested that the proposed syntax for specifying the values of the AMI
parameters is insufficient if the same parameter name appears in multiple
branches.  Michael agreed that this was an issue he hadn't considered.  Arpad
asked whether we should just specify the exact parameter string to be passed to
the model.  Michael said his concern was that we would have to be very careful
to make sure the model maker understands the syntax of the parameters string.
Michael said he would work on improving this section of the proposal, as Arpad's
concern was valid and needed to be addressed.

- Michael: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

New ARs:

Bob: Send information about the recent IEEE SPI IBIS Summit presentation on PSIJ
     to the ATM list.

-------------
Next meeting: 20 Jun 2023 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
